Dynomotion

Group: DynoMotion Message: 6973 From: az9633@ymail.com Date: 3/13/2013
Subject: Initiating G code prog
I would like to start the G code program in K CNC with an I/O input bit. How can I do that? I would also like to use the M1 (optional stop) function with I/O

AZ
Group: DynoMotion Message: 6975 From: Tom Kerekes Date: 3/13/2013
Subject: Re: Initiating G code prog
Hi AZ,

You can perform things like Cycle Start and Halt as shown in the example: 

KFLOPtoPCCmdExamples.c

There is a WaitBitBuf command to hold GCode until an Input is activated.  See:

http://www.dynomotion.com/Help/KMotionCNC/SynchronousIOCommands.htm

Regards
TK


Group: DynoMotion Message: 7000 From: az9633@ymail.com Date: 3/17/2013
Subject: Re: Initiating G code prog
Hi Tom,
Is there a way to insert a WaitBitBuf command into the G code processing with an M code call to a C program?

The WaitBitBuf is a mouthful for an operator to program especially if he has to do it 100 times per part program.

Can I call a subroutine as part of the G code that will do a find/replace edit to replace say a "P" on a line with WaitBitBuf?

Does an M code on its own line to set a bit in between two G00 moves result in any delay in processing the next move?

Thanks Tom
AZ

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi AZ,
>
> You can perform things like Cycle Start and Halt as shown in the example: 
>
> KFLOPtoPCCmdExamples.c
>
> There is a WaitBitBuf command to hold GCode until an Input is activated.  See:
>
> http://www.dynomotion.com/Help/KMotionCNC/SynchronousIOCommands.htm
>
> Regards
> TK
>
>
>
>
> ________________________________
> From: "az9633@..." <az@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, March 13, 2013 7:42 AM
> Subject: [DynoMotion] Initiating G code prog
>
>
>  
> I would like to start the G code program in K CNC with an I/O input bit. How can I do that? I would also like to use the M1 (optional stop) function with I/O
>
> AZ
>
Group: DynoMotion Message: 7019 From: Tom Kerekes Date: 3/18/2013
Subject: Re: Initiating G code prog
Hi AZ,

Here is a new Test Version 4.31b that allows configuring an M Code for a WaitBitBuf delay.

Please test it for us.

http://dynomotion.com/Software/KMotion431b.exe

An M code on the same line or previous line shouldn't make any significant difference in timing.

Regards
TK

Group: DynoMotion Message: 7037 From: az@aimele.com Date: 3/19/2013
Subject: Re: Initiating G code prog
Thanks for the Beta program.
What would be the difference between the WaitBitBuf and an Mcode with Execute/Wait C program.?

This application is pretty simple.  We need to be processing the M code commands and holding the program flow in betwen moves while the axes are stopped.

Thanks
AZ

------- Original Message -------
From : Tom Kerekes[mailto:tk@...]
Sent : 03/18/2013 3:14:03 AM
To : DynoMotion@yahoogroups.com
Cc :
Subject : RE: Re: [DynoMotion] Re: Initiating G code prog

 

Hi AZ,

Here is a new Test Version 4.31b that allows configuring an M Code for a WaitBitBuf delay.

Please test it for us.

http://dynomotion.com/Software/KMotion431b.exe

An M code on the same line or previous line shouldn't make any significant difference in timing.

Regards
TK

Group: DynoMotion Message: 7048 From: Tom Kerekes Date: 3/19/2013
Subject: Re: Initiating G code prog
Hi AZ,

The WaitBitBuf is real-time deterministic.  The MCode with Execute/Wait is not.  The Execute/Wait involves Windows/PC/USB so will usually involve a few milliseconds of delay but sometimes a second or more.  The WaitBitBuf is guaranteed to respond within 90us.

Regards
TK


Group: DynoMotion Message: 7055 From: az@aimele.com Date: 3/19/2013
Subject: Re: Initiating G code prog
Tom:

I think I understand that the first time an Execute/wait is run it has to pull the program from the PC, load it into the K flop and run it.
But I thought that once it is loaded into the K flop into a thread, it stays in the Kflop and on subsequent calls it just runs that thread WITHOUT  involving the PC.  It would seem that should be pretty quick.  This isn't deteministic like the Wait Bit Buf but a few milliseconds in this application won't be noticed however, more than 100 milliseconds might and a full second will.  Am I missing something?

AZ

------- Original Message -------
From : Tom Kerekes[mailto:tk@...]
Sent : 03/19/2013 12:01:14 PM
To : DynoMotion@yahoogroups.com
Cc :
Subject : RE: Re: Re: [DynoMotion] Re: Initiating G code prog

 

Hi AZ,

The WaitBitBuf is real-time deterministic.  The MCode with Execute/Wait is not.  The Execute/Wait involves Windows/PC/USB so will usually involve a few milliseconds of delay but sometimes a second or more.  The WaitBitBuf is guaranteed to respond within 90us.

Regards
TK


Group: DynoMotion Message: 7056 From: Tom Kerekes Date: 3/19/2013
Subject: Re: Initiating G code prog
Hi AZ,

No it is actually compiled and downloaded each time.  There is a way to just execute the Thread again if you know a program has already been downloaded to that Thread.  Just don't specify a file name to be compiled and downloaded.

But regardless in either case it still involves the PC/Windows/KMotionCNC/Interpreter receiving a response through USB that the motion is finished, and then sending a command through the USB for the Thread to Execute.  At a minimum some code on the PC must execute.  If just at that moment Windows decides it must shuffle virtual memory and to do that it must wait for some Process to finish what it is doing, which needs something else to finish its task, ...etc...etc... there can be a big delay.  These delays will occur vary rarely but they do happen.  For many applications it doesn't matter if a 2 hour job takes 2 extra seconds to complete because of several unnecessary delays.  But if a Laser occasionally stays on for an extra second it might burn a hole through the part.

HTH
Regards
TK